fix(mcp): launch the Chrome profile that has the extension installed by dcrousso · Pull Request #41939 · microsoft/playwright

dcrousso · 2026-07-22T17:04:14Z

extension mode validated that the playwright extension was installed in any of Chrome's profiles under the user data directory, but then launched without --profile-directory, meaning it could open a different profile than the one that was checked

when the opened profile lacks the extension, connect.html can't load and the connection silently hangs for ~120s

resolve the profile that actually has the extension (preferring the last-used profile from Local State so we don't switch away from the user's session unnecessarily) and pass it as --profile-directory

fixes #41916

yury-s · 2026-07-22T17:19:27Z

+      args.push(`--user-data-dir=${testUserDataDir}`);
+    const userDataDir = testUserDataDir ?? this._userDataDir;
+    const profileDirectory = userDataDir ? await findPlaywrightExtensionProfile(userDataDir) : undefined;
+    if (profileDirectory)


does it work in edge too?

yury-s · 2026-07-22T17:21:08Z

+  const userDataDir = test.info().outputPath('multi-profile');
+  await fs.mkdir(path.join(userDataDir, 'Profile 5', 'Extensions', extensionId), { recursive: true });
+
+  const executablePath = test.info().outputPath('echo.sh');


can we do e2e test instead and run chrome with 2 real profiles?

yury-s · 2026-07-22T17:22:11Z

+  const userDataDir = test.info().outputPath('multi-profile-last-used');
+  await fs.mkdir(path.join(userDataDir, 'Default', 'Extensions', extensionId), { recursive: true });
+  await fs.mkdir(path.join(userDataDir, 'Profile 5', 'Extensions', extensionId), { recursive: true });
+  await fs.writeFile(path.join(userDataDir, 'Local State'), JSON.stringify({ profile: { last_used: 'Profile 5' } }));


Ditto. We already parse chromium private data structures and we want to know if it breaks.

yury-s · 2026-07-22T17:24:22Z

+    const userDataDir = testUserDataDir ?? this._userDataDir;
+    const profileDirectory = userDataDir ? await findPlaywrightExtensionProfile(userDataDir) : undefined;
+    if (profileDirectory)
+      args.push(`--profile-directory=${profileDirectory}`);


maybe we should accept an option for explicit profile selection (the directory names don't match profile names in the ui though)?

added a --profile-directory option and PLAYWRIGHT_MCP_PROFILE_DIRECTORY environment variable

Commented below, let's remove it for now.

yury-s

let's drop --profile-directory option for now, otherwise looks good

yury-s · 2026-07-22T19:20:16Z

      .option('--output-dir <path>', 'path to the directory for output files.')
      .option('--output-max-size <bytes>', 'Threshold for evicting old output files, in bytes.', numberParser)
      .option('--port <port>', 'port to listen on for SSE transport.')
+      .option('--profile-directory <directory>', 'in extension mode, the browser profile directory to connect to (for example "Default" or "Profile 1"). Defaults to the profile that has the extension installed.')


Let's hold off, we already have --user-data-dir option and this just adds to the confusion (there is no easy way for the user to guess which of "Profile N" corresponds to the user profile "Foo"). If there is demand we can add it later. We'd also need to expose it as an option in playwright-cli.

yury-s · 2026-07-22T19:20:54Z

+    const userDataDir = testUserDataDir ?? this._userDataDir;
+    const profileDirectory = userDataDir ? await findPlaywrightExtensionProfile(userDataDir) : undefined;
+    if (profileDirectory)
+      args.push(`--profile-directory=${profileDirectory}`);


Commented below, let's remove it for now.

yury-s · 2026-07-22T19:40:02Z

+    headless: false,
+    ignoreDefaultArgs: ['--enable-automation'],
+    args: [
+      `--profile-directory=${profile}`,


does it actually create a new profile?

i believe so, but given your comment below im removing this

yury-s · 2026-07-22T19:43:19Z

+  await createProfile(userDataDir, 'Default', mcpBrowser);
+  await createProfile(userDataDir, 'Profile 1', mcpBrowser, pathToExtension);
+
+  const executablePath = testInfo.outputPath('echo.sh');


this is still just a unit test for the logic in our code that constructs the parameters, in that case let's just keep one simple test and it's okay to create mock profiles manually

extension mode validated that the playwright extension was installed in any of Chrome's profiles under the user data directory, but then launched without `--profile-directory`, meaning it could open a different profile than the one that was checked when the opened profile lacks the extension, `connect.html` can't load and the connection silently hangs for ~120s resolve the profile that actually has the extension (preferring the last-used profile from Local State so we don't switch away from the user's session unnecessarily) and pass it as `--profile-directory`

github-actions · 2026-07-22T21:03:16Z

Test results for "MCP"

1 failed
❌ [firefox] › mcp/cli-devtools.spec.ts:173 › response-body returns just the body @mcp-windows-latest-firefox

7785 passed, 1262 skipped

Merge workflow run.

github-actions · 2026-07-22T21:06:34Z

🟡 One failure I can't pin down — leaning unrelated

Hi, I'm the Playwright bot and I took a first look at the CI failures.

The latest run has a single failure: [firefox] › mcp/cli-devtools.spec.ts:173 › response-body returns just the body on mcp-windows-latest-firefox. Your diff shouldn't be able to reach it — every change here is extension-mode-only, and this is the plain (non-extension) firefox network path. But it's never failed anywhere else in the results DB, so I can't call it a proven flake. Uncertain, leaning unrelated.

Details

Overall: this PR only touches MCP extension mode. All four changed paths — cdpRelay.ts (_openConnectPageInBrowser), extensionContextFactory.ts (createExtensionBrowser), utils/extension.ts (findPlaywrightExtensionProfile), and tests/extension/extension.spec.ts — run behind the extension branch. The failing test doesn't exercise extension mode.

Uncertain

[firefox] › mcp/cli-devtools.spec.ts:173 › response-body returns just the body (mcp-windows-latest-firefox) — failed with expect(received).not.toBeNull() / Received: null: the response body came back null. In the results DB this test has passed every other run — chrome 1200/1200, chromium 1200/1200, firefox 1172/1173, webkit 1210/1210, msedge 396/396 across 400+ SHAs each — and the only failure is this one, on your PR's SHA (23ae27b). Because I can't cite it failing anywhere the PR isn't responsible for, I won't label it a flake. But the diff is entirely extension-gated and this is the ordinary firefox devtools/network flow, and a lone null-body on one OS/engine reads like a startup or timing hiccup. To settle it, re-run the job: green on retry with no code change confirms it's not yours.

_{Triaged by the Playwright bot - agent run}

dcrousso requested a review from yury-s July 22, 2026 17:04

yury-s approved these changes Jul 22, 2026

View reviewed changes

This comment has been minimized.

Sign in to view

dcrousso force-pushed the fix-41916 branch from 516728e to cd14911 Compare July 22, 2026 19:11

yury-s approved these changes Jul 22, 2026

View reviewed changes

This comment has been minimized.

Sign in to view

dcrousso force-pushed the fix-41916 branch from cd14911 to d8e89c4 Compare July 22, 2026 20:19

dcrousso merged commit 0edafe4 into microsoft:main Jul 22, 2026
17 of 18 checks passed

dcrousso deleted the fix-41916 branch July 22, 2026 21:04

JustasMonkev mentioned this pull request Jul 23, 2026

fix: sync MCP download and extension profile handling JustasMonkev/mcp-accessibility-scanner#136

Merged

dcrousso mentioned this pull request Jul 24, 2026

fix(mcp extension): look for extension profile in default user data dir #41972

Closed

github-actions Bot mentioned this pull request Jul 24, 2026

fix(mcp): reconnect to the browser after disconnect #41966

Open

Uh oh!

Conversation

dcrousso commented Jul 22, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

This comment has been minimized.

yury-s left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

This comment has been minimized.

This comment has been minimized.

github-actions Bot commented Jul 22, 2026

Test results for "MCP"

Uh oh!

Uh oh!

github-actions Bot commented Jul 22, 2026

🟡 One failure I can't pin down — leaning unrelated

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants